The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field. Still more particularly, the present invention relates to a system and method for protecting the integrity of dependent multi-tiered transactions.
Transaction processing systems provide the facility of defining a series of events under a single unit of work that may be committed or rolled back together, maintaining the integrity of the complete unit of work. The XA standard is an X/Open specification for distributed transaction processing (DTP). It describes the interface between the global transaction manager and the local resource manager. The idea of transactionality has been extended through with the introduction of the concept of Global transactions that maintain a single unit of work across multiple resource managers. Although this concept resolves the issues revolving around maintaining a global transaction context over multiple resource managers through the transaction manager, it does not address the n-tier requirements for transaction integrity when the data from one transaction in tier n is utilized in tier n+1.
Under the prior art, tier n+1 can access the input data from tier n only after the tier n transaction has been committed. This is true in the case of a single transaction or an XA global coordinated transaction. The workaround provided by most n-tier transaction workflow designs is to have a compensating transaction for a failure at a higher tier. This does not provide guaranteed transaction integrity across multiple tiers and may often lead to extremely serious consequences since the data is not protected during the period when the data is committed by the transaction at tier n and the compensating transaction reverting back the data.
The concept of a Transaction (tx) was introduced to maintain application and resource integrity in the sense that a logical unit of work comprising of multiple accesses to resources can be either committed or rolled back atomically. Transactional systems such as database managers and middleware resource managers can now maintain the atomicity of a unit of work on a set of resources by locking access to the new data from other applications competing for the same resources until the unit of work is complete. Thereafter the data is unlocked for other applications to use. This system of locking and unlocking guarantees the data integrity in the set of resources for each atomic unit of work, or, in other words, the transaction.
Unfortunately, when multiple resource managers participate in the same unit of work, the transactions are not coordinated and the atomicity and integrity is lost. This issue is addressed by introducing the concept of Global Transaction (gtx) where a single unit of work can be distributed on multiple Resources Managers (RM), maintaining integrity of separate sets of resources. The resource managers maintain the integrity of the set of resources that it is responsible for and participates in a global transaction so that the transactions can be coordinated from a global space in a two-part commit operation maintained by the Transaction Manager (TM). Thus, the integrity of the resources participating in the global transaction is maintained by the TM.
An application (AP) starts a transaction with the transaction manager (TM), which in turns starts the transaction with all the resource managers registered with the TM, viz. RM1 and RM2, by passing the global transaction identifier (xaid) to identify the global context. The application (AP) gets a message from the queue manager (RM1), inserts the data from the message into a database table maintained by the database manager (RM2) and puts a confirmation message into a queue maintained by the same queue manager (RM1). Thereafter, the AP commits the transaction which tells the transaction manager to do a two-part commit, i.e., sends a ‘prepare to commit’ to all the resource managers, and, when the confirmation returns XA_OK, signifying that they have successfully done maintenance and are ready to commit, the TM sends the actual commit signal. This provides assured commitment for all the resource managers in the transaction manager's domain. A mechanism is also provided for remote resource managers belonging to the same or different transaction manager domains to communicate and coordinate transaction commitment.
The TM maintains the atomicity of the global transaction with other independent transactions maintained within the RM. In the case of dependent transactions the atomicity of the global transaction is lost. This is true in the case of transactions participating outside the global transaction as well. To illustrate the point, consider a very simple transactional operation. An application (APP1) writes a message to a queue and commits the transaction (T1). Another application (APP2) reads the message from the queue under transaction (T2), tries to process the data from the message, and fails. APP2 can now decide to rollback the transaction T2 and the messages are restored in the queue.
The upstream transaction cannot, however, be rolled back at this point. The only way the previous state can be restored is to have a compensating transaction (T3) that does exactly the opposite of what T1 did. That approach necessitates that the atomicity of the two transactions working in tandem is lost. Consider another application (APP3) that reads the same queue or an administrator intervening before T3 was processed. This will lead to loss of integrity of T1 and T2 working in tandem to achieve an atomic goal. Applications need to handle each of these conditions separately and try to maintain atomicity for (T1+T2), which will only get exponentially more complex as more and more applications and resource managers are brought into the picture.
What is needed is a solution for protecting the integrity of transactions over multiple tiers.